Here are some tools that let you attach a script to any dialog item in a modal dialog or menu item. This is a proof of concept rather than something that will be available in the system in future. It does let you glimpse into the future when you can attach scripts to every user interface object.
TinkerDlogInit should be put in the system extension folder. It patches out GetNewDialog, ModalDialog and other traps. So you may not want to leave it in your system all the time. However, it is in my system for the last half years without any ill effect. Also once tinkering occurs, it connects to the scripting component until the application quits and this may take up a lot of room in your system heap. Tinker Dialog OSAX tells the scripting system about the tinkering terminology and it should be in the scripting additions folder. SimpleDialog is just a simple application to try tinkering out before you try to tinker other application.
This is not meant for the end user and there is no user interface to the tinkering, so you have to use Toy Surprise or the ResEdit to develop your script and edit the necessary resource. The event and the class and property you can use are all in the aete resource of the OSAX. Here is the terminology as seen from Toy Surprise.
dialog suite:
tinker setdata: Same as setdata, just in case some application would not pass setdata event to system handler
tinker setdata
To '****'
tinker keystroke: post keystrokes to the event queue
tinker keystroke string
tinker open: open the dialog by id or by name and then do a modal dialog
tinker open
Result: 'shor'
tinker getdata: same as getdata just in case application would not pass getdata to system handler
tinker getdata
As 'type'
Result: '****'
getdata: the core getdata event
getdata
As '****'
Result: '****'
setdata: the core setdata event
setdata
To '****'
my application: return psn = kCurrentProcess, not needed in future
my application
Result: 'psn '
Class application:
Elements:
ditl item by numeric index
dialog by name
dialog 'ID '
Properties:
name 'itxt'
Class ditl item: the items in a dialog
Properties:
rectangle 'qdrt' (the location of the dialog item)
visible boolean (is the item visible?)
hilite boolean (is the item enabled?)
name 'itxt' (title of the button)
ditlkind Button/CheckBox/RadioButton/Control/Static Text/Editable Text/Icon/Picture/UserItem (the kind of dialog item)
selection list (the selection range of the edit item)
Class dialog:
So you can write script that get and set various property of the dialog in object model style. However whose clause is not supported.
To do the tinkering, make a script file using TS or ‘scpt’ editor, then copy the 'scpt' resource to the application (must be HLE aware). You can pick your own resource ID. Find the ID of the dialog and the item number(s) of the dialog item you want to tinker with. Let say the Dialog ID is 201, then you create a 'sdlg' resource with ID 201. The 'sdlg' template is included here. In the 'sdlg' resource, for each dialog item you want to attach a script, you can enter the item number, the script type 'scpt' and the resource ID of the script you want to trigger. For menu tinkering you do the same except with 'smnu' resource where the resource id is the menu id and the item number is the menu item number. After that just run the application after launching Gustav and the target application in the script.
The dialog you tinker can be system dialog such as standard file or the print dialog. You should be able to put the 'sdlg' and 'scpt' resource in system file and affects all HLE aware application.
We have include a simple program call SimpleDialog to try out the tinkering. SimpleDialog does nothing but search for all the ‘DLOG’ resource in itself (so you can put in more dialog of your own) and put the names of the ‘DLOG’ resource on the menu. When you pick the menu item, it just load the dialog and do a ModalDialog. There is also a menu item for you to tinker with. There is a menu item to send an Apple Event to another application. The idea is that you can then send it to a remote application so the the authentication dialog will be invoked and you can try to tinker with it.
Here are some of the scripts in SimpleDialog
for radio button
tell (my application)
if not ditl item 4 then -- if it is not already on
set ditl item 4 to true -- turn myself on
set ditl item 9 to false -- and turn the other radio button off
end if
return 0 -- tell tinkering INIT that action is completed
end tell
“my application” is an OSAX function. it is only needed in this version to get around some problem to make it more reliable. The tell block is not necessary in future.
for opening a dialog from the menu
tell (my application)
tinker open dialog ID 129 -- just do a modal dialog for dialog 129
return 0
end tell
to swap the pictures in the dialog
tell (my application)
copy ditl item 3 to x -- put a PICT into x
copy ditl item 4 to y -- put a PICT into y
set ditl item 3 to y -- put PICT from item 4 to 3
set ditl item 4 to x -- put PICT from item 3 to 4
return 0
end tell
For authentication, replace "password" by your password. Leave the "/3". The "/3" should really be & Enter in future.
tell (my application)
if hilite of ditl item 8 then -- if we have guest log on
return {8, 1} -- hit the guess radio button and then OK button
else
tinker keystroke "password/3" -- type in password, then enter key
return {}
end if
end tell
This script let you dismiss the authentication dialog with either guest logon or your own password. This script also brings up interesting points about tinkering. You must realize that when you are tinkering a dialog, the application or system may not aware that you are change the state of the various dialog items since it expects that to be done by user action only. Therefore when you want to hit the radio button for guest logon, while
set ditl item 8 to true would indeed change the guest radio button, the system in this particular case is not aware of it, that is why you need to return {8, 1} so that it is in the hit list. Similarly, if you set the content of the password field, the system is unaware of it and that is why you need to post the keystroke by the tinker keystroke call.
Another earlier failure in tinkering is to let the user pick the printer from the print dialog. The printer was indeed selected, but the print dialog routine is not aware of it so it still print with the old printer selection. The default printer switch only occurs after the current print, thus defeating its purpose. This indicates that tinkering can be tricky, require a lot of experimentation. However it can be quite rewarding. For example, you can put the authentication tinkering dialog in the system folder and solve one of the biggest hassle of using remote Apple Events. If you do this, you may want to change the script resource ID to avoid conflict with any other script in the application.
